Cream of the Crop 11

home *** CD-ROM | disk | FTP | other *** search

/ Cream of the Crop 11 / Cream of the Crop 11-2.iso / os2 / adept106.zip / GATEKPR.DOC < prev next >

Wrap

Text File | 1995-12-21 | 50KB | 1,253 lines

---------------------------------------------------------------------- GateKeeper Documentation Copyright (c) 1993 - 1996 by AdeptSoft portions Copyright (c) 1991-1994 M. Kimes All Rights Reserved AdeptSoft, AdeptXBBS, GateKeeper, are trademarks of AdeptSoft. "XBBS" Copyright (c) 1988 - 1994 by M. Kimes. The "XBBS" name is a Trademark of M. Kimes. ---------------------------------------------------------------------- TABLE OF CONTENTS CONTACTING ADEPTSOFT.............................................1 GATEKEEPER CONTROL DOCUMENTATION.................................2 COMMAND LINE OPTIONS FOR GATEKPR.EXE:............................2 THE AREA.CONTROL FILE............................................12 THE FILE.CONTROL FILE............................................15 OUTBOUND MAIL NAMING CONVENTIONS.................................19 AREAFIX TYPE COMMANDS............................................20 TEXT FILES USED WITH THE MAILER..................................21 OK FILES:...................................................... 21 OTHER TEXT FILES USED WITH THE MAILER:......................... 21 CONFIGURABLE MAIL DIRECTORIES:................................. 21 BAD MAIL PACKET FILE DESCRIPTIONS:............................. 22 REPORTING BUGS...................................................23 1 __________________________ _ _ CONTACTING AdeptSoft _ __________________________ AdeptSoft is located in Boca Raton, Florida. Our current mailing address is: AdeptSoft 3465 NW 27th Avenue Boca Raton, FL 33434 AdeptSoft can be reached via the following methods: Telnet: bbs.adeptsoft.com FTP : ftp.adeptsoft.com WWW : WWW.adeptsoft.com FidoNet: 1:18/210.0@Fidonet You may also contact us at our support BBS at the number: (407) 477-6310, 28.8K 2 ______________________________________ _ _ GATEKEEPER CONTROL DOCUMENTATION _ ______________________________________ GateKpr.Ctl is a control file that tells Gatekeeper how to behave. You can put all your information into GateKpr.Ctl. GateKpr.Ctl and AREA.CONTROL are parsed in the exact same manner, and a keyword can be placed in either. We just cut most of the area stuff, and allowed SysOps to place area info in the AREA.CONTROL file to make it easier to keep organized. Note: FILE.CONTROL is parse differently, so it must be separate. Command Line Options for Gatekpr.Exe: /E - Do mail export /I - Do mail import /IP - Set GateKeeper to run at Idle PrioritY /C - Do group mail cleanup /A - Do All (Import/Export/TIC) <Default> /MP - Set GateKeeper to run at maximum priority /NG - No group mail processing /NE - No echo mail processing /NP - Set GateKeeper to run at normal priority /F - Fully moderated group mail OK /FI - Do TIC processing /P - Partially moderated group mail okay /RO - Do mail routing /LP - Set GateKeeper to run at Low priority /HP - Set GateKeeper to run at High Priority The following is a list of commands that can be in your GateKpr.Ctl file. AREAFILE This tells GateKeeper the name of your Area Control file. See the section in this document that deals with the AREA.CONTROL file for more info on what it does. Ex. AREAFILE AREA.CONTROL MAXDUPES #### Dupe detection. Adept uses two methods of dupe detection, both are extremely reliable and effective. In order to turn dupe detection on you MUST specify BOTH the Maximum number of dupes checking records to keep (MAXDUPES). The MAXDUPES keyword allows you to specify the maximum number of dupe records to keep. Each dupe record is 8 bytes in size. If you want to keep dupe records for the last 1000 messages it will be a 8k file. The size of the dupe file for 8192 messages will be 64k Ex. MAXDUPES 1024 KEEPDUPES The KEEPDUPES keyword tells the BBS software to toss duplicate messages to the file AREDUPES.$$$ if you rename this file to AREDUPES.PKT the BBS software will toss the file, ignoring the duplicate messages. 3 Ex. KEEPDUPES NODUPECHECKING The NODUPECHECKING keyword turns off dupe checking entirely, no matter what other options are set. Ex. NODUPECHECKING INBOUND You can have as many inbound areas you want with Gate Keeper. The inbound area is where Gate Keeper will look for incoming .PKT's or Archived mail packets. Ex. INBOUND C:\ADEPT\MAILER\PUBLIC_INBOUND INBOUND C:\ADEPT\MAILER\PRIVATE_INBOUND OUTBOUND You can only have one outbound directory with Gate Keeper. The outbound directory is where Gate Keeper will place outgoing mail packets both archived or otherwise. Ex. OUTBOUND C:\ADEPT\OUTBOUND_MAIL MSGDIR The MSGDIR is where adept will default to placing incoming messages for your Adept Message base. Please realize Gate Keeper also reads the Adept Message_Areas control file so that it can check and see if you chose another directory to place the messages in. Ex. MSGDIR C:\ADEPT\MESSAGE_BASES ADDRESS Gate Keeper requires a 5-D FidoNet style mail address. YOU CAn have as many addresses as you want. Any domain name over 8 characters is not to fido specs, and Gate Keeper may not operate as you expect.. Use large domain names at your own risk. At least the first 8 characters must be unique. The below example shows 3 addresses on a address line. Multiple Address lines are allowed and each line can be up to 1024 chars. Please remember to use a 5-D mail address. Ex. ADDRESS 1:18/210.0@Fidonet 55:50/0.0@AdeptNet ##:##/##.##@OtherNet NETAREA <message area #> The NetArea tag sets the default message area in Adept that Gate Keeper will scan for Net Mail. This message area # must match an existing message area in Adept. Gate Keeper will place incoming NetMail into this area also. Ex. NETAREA 99 LOGFILE The logfile tag sets the name of the Gate Keeper Log File. This keyword should be at the top of your GateKpr.Ctl file. When you specify the LOGFILE keyword, Gate Keeper will immediately open the log file. If you specify the LOGFILE keyword again, it will close the open logfile, and then open a new one. It would allow you to do something like: LOGFILE GateKprConfigErrors.Log .. Read in all control files 4 .. at the end of the last control file (most likely AREA.CONTROL) .. have this line LOGFILE GateKprRun.Log In this way you could log config errors to one file, and then log the actual run time to another log. You do not have to do this though, you can have one log file that you open at the top of your GateKpr.Ctl file and be done with it. Ex. LOGFILE C:\Adept\GateKeeper.Log PACKSIZE Smallest msg size that GateKeeper will try to pack into a smaller size using LZSS compression (into the Adept message base). Any message smaller than, say, 512 bytes doesn't get compressed much. Ex. PACKSIZE 8192 NOTINY The NOTINY flag tells GateKeeper not to use TINY SEENBY's in mail processing. Regular SEENBY's are pretty much useless and just plain extra baggage. You only want to turn this on if you are SURE this is what you want. By default GateKeeper turns SEEN-BYs into 'tiny' SEEN-BYs which remove most of the seen-bys. and just keep ones from the local net.. and this can remove up to a 1/3 of a msgs size. SEEN-BYs are as useless as PATH statements, the only difference is that SEEN-BY lines are required by FTSC spec, PATH lines aren't. Ex. NOTINY NOFORWARD Tells GateKeeper NOT to forward 'foreign' mail. By 'foreign', we mean mail not destined to any person in the current systems net. 'local' is a node which is in the same net. 'Foreign' is anyone else. Now, if the SysOp chooses NOFORWARD, GateKeeper will put that routed netmail in a FORWARD.$$$ packet. If the SysOp adds the KEEPNOFORWARDS keyword, then GateKeeper will not even bother to toss the routed netmail into the FORWARD.$$$ file. In other words, it dissappears. If neither of those keywords are in place, then netmail gets routed. This is the default. If the SysOp does not want to forward 'local' routed netmail, they should use the NOLOCALFORWARD keyword instead of the NOFORWARD keyword. KEEPNOFORWARDS also works for local routed netmail. Ex. NOFORWARD NOLOCALFORWARD Tells GateKeeper not to forward local mail within your net. Ex. NOLOCALFORWARD KEEPPATH Tells GateKeeper to put 5D SPTH lines into your Adept messages. This may or may not be a bad thing. It will take up more space in your message bases. But does keep necessary info for FidoNet in the Adept message base. 5 Ex. KEEPPATH KEEPSEENBYS Tells GateKeeper to KEEP EchoMail SEENBY lines when importing them into the message base. Ex. KEEPSEENBYS TONAME "NAME" <OPTION> The TONAME tag is a very special tag. This tag allows you to turn on special functions like Areafix. See the section in this document on Areafix for more info on this subject. The various options available are listed below: AREACNTL This message is a Areafix Control Message. Ex. TONAME "Areafix" AREACNTL ROUTE Means to forward this message to someone. The node to route this message to follows the ROUTE keyword. Use 5-D addressing. Ex. TONAME "Gramps" ROUTE 1:213/760.0@FIDONET MSG If message is TO this person, make a .MSG file containing the message. This is a FIDO style .MSG file. The directory where this message is put is specified with the MESSAGES keyword: MESSAGES C:\Adept\FidoStyleMsgs Ex. TONAME "Any Name" MSG PROG This cause Gate Keeper to write this message as .MSG file, then will run a specified program after it writes the msg file. Ex. TONAME "Lisa" PROG ProcessMsg.Cmd The command line is executed as: CMD.EXE /c ProcessMsg.Cmd 1.MSG KILLBADDATES The KILLBADDATES flag tells GateKeeper to trash all messages with a bad dates field. Ex. KILLBADDATES ALLOWBADAREAS The ALLOWBADAREAS tells GateKeeper to NOT delete messages with a BAD AREA: tag. Ex. ALLOWBADAREAS DELETEINSECURE Variable that tells GateKeeper to send all INSECURE messages to the digital trash can in the sky. Ex. DELETEINSECURE 6 NOUNKNOWN Tells GateKeeper *NOT* to make UNKNOWN.PKT packets. This option is useful if you are tossing things like planet connect and have hundreds of Echos you DON'T want sitting on your drive because they are 'UNKNOWN' Ex. NOUNKNOWN ACKNOWLEDGERRQ This stands for 'Acknowledge Receipt Request' If a FidoNet message has a MSGRRQ flag set (Receipt Request flag) then GateKeeper will automatically send a message back to the sender which says "Your message has been received.." etc. By default a message is not sent back to the sender even when the MSGRRQ flag is set. Ex. ACKNOWLEDGERRQ MAXTOHIBIT ## The MAXTOHIBIT flag defines the maximum number of high bit characters to allow in the To: field of a message before it's considered a trashed message. Ex. MAXTOHIBIT 5 MAXFROMHIBIT The MAXFROMHIBIT flag defines the maximum number of high bit characters to allow in the To: field of a message before it's considered a trashed message. Ex. MAXFROMHIBIT 5 MAXSUBJHIBIT - The MAXSUBJHIBIT flag defines the maximum number of high bit characters to allow in the To: field of a message before it's considered a trashed message. Ex. MAXSUBJHIBIT 5 NOROUTENET Tells GateKeeper not to pack NetMail with the rest of a node's mail. If the message is netmail, and the SysOp has chosen NOROUTENET, GateKeeper will create a 'T' flavor packet, rather than a 'P' type (or regular packet) 'T' packets aren't routed or packed. They are just sent to the system as a plain packet. Consider the T type packet a unarchived netmail packet. Ex. NOROUTENET NOROUTEPOINTS The NOROUTEPOINTS keyword causes normal routing to take place, (ie. thru the ROUTE command) to the points. By default mail to points is routed. This means that mail being sent to points is sent to that points boss node. ie. the .0 system. If you set NOROUTEPOINTS GateKeeper will route 'local' point mail directly to the point system. No matter what, any point mail destined for a point that is not in the current systems net is routed to the boss node. Ex. NOROUTEPOINTS ARCHIVE 7 Sets the default archiving command for GateKeeper. UNARCHIVE Sets the default unarchiving command for GateKeeper. If GateKeeper finds the file type in the Archivers file, it will use the archive and unarchive commands found in it. If not, it will try to use the default archive and unarchive commands on a file. The default ARCHIVE command is: "ZIP.EXE -mj" To change this, use the ARCHIVE keyword. The default UNARCHIVE command is: "UNZIP.EXE -oj" To change this, use the UNARCHIVE keyword. The default UNARCHIVE command is overridden by information in the Adept/GateKeeper "Archivers" file. The default UNARCHIVE command is used only if: 1) There is no "Archivers" file. 2) The archived mail bundle doesn't match any archive type found in the "Archivers" file. 3) There is no 'extract' command for the archiver type found in the "Archivers" file. The ARCHIVE command is always overridden by the information in the ROUTE keyword. ROUTE <Address mask> <type> <route to> <archive command> <Address Mask> Address mask is actually a filename mask. Any filename which fits the address mask gets routed according to that entry. Basically, if the address mask is: 1.213.*.*.* GateKeeper will look for all files called P.1.213.*.*.* If you do a directory from the command prompt you will see what files fit that: [C:] dir P.1.213.*.*.* That's basically what GateKeeper does. So if you have a specific node which gets special treatment, it should go before the more generic address mask statement. For instance, if 1:213/761 needs LZH archiving you would want to put an entry for it before the generic 'all nodes in 213' statement. ROUTE 1.213.761.*.* etc. LH.EXE ROUTE 1.213.*.*.* etc. ZIP.EXE If a packet (P.*.*.*.*.*) doesn't fit into a route statement, it won't be archived. 8 <type> can be "Crash", "Hold", "Direct", "Normal", "Manual" Type is the flavor of attach should be used for this entry. This is typical FidoNet stuff. Crash, Direct, Hold, Normal. The first letter is all that counts here. C, D, H, N, M If the letter isn't one of those 5, the default changes it to Hold. All this statement does is cause GateKeeper to create a file attach with the flavor specified. So if mail was packed for 1:213/760.0.FIDONET and it was specified as Normal, then a file attach with the filename N.1.213.760.0.FIDONET would be created. The letter of the Type is the first letter of the attach. The file attach affects how Adept works. Normal flavor attaches should be sent during any session with a particular session whether they called us, or we called them. Hold flavor attaches are only looked for if they called us. If we are being called, or we are doing a poll (using the poll dialog.. not a regular call) then the M flavor attaches are looked for. M stands for Manual. A packet of this flavor is only sent if the receiver of the mail polls us, or that we 'manually' poll them This mail is not sent during a normal call that we would make. This would control when the mail is sent. ie. the mail is only sent if we manually tell Adept to do so. <route to> can be 5D-Address, "Same", "PointRoute", "HostRoute" This can be 4 different things: 5D Address: Means that mail fitting the address mask is sent to this 5D address, whether or not it is the same system. Same: Means that mail fitting the address mask is sent to the same address. ie. You want to route the mail to the system it is intended for. Pointroute: Means that for mail fitting the address mask, you don't want to send mail to points, but that you want to route it to the boss node.. ie. Zone.Net.Node.0 Hostroute: Means that mail fitting the address mask should be routed to the Host system of the net.. ie. Zone.Net.0.0 In most cases, you would want to use SAME <archive command> The program and parameters you want to use to archive the mail. When a ROUTE line contains no archive command, the file is renamed to a FTN style PKT name, then the filename is added to a file attach to the specified node in the flavor (C,D,H,M,N) asked for. Ex. ZIP.EXE -m -j Questions and Examples of the ROUTE keyword: Q: Which of the following is correct, or does it matter: 9 ROUTE 500.601.42.*.* Crash Same ZIP.EXE -m -j ROUTE 500.*.*.*.* Hold Same ZIP.EXE -m -j -or- ROUTE 500.*.*.*.* Hold Same ZIP.EXE -m -j ROUTE 500.601.42.*.* Crash Same ZIP.EXE -m -j A: Both are correct, though the second won't work as planned. If you have specific routing for a node, put it first, the do general routing second. So the first entry is more correct than the second. Q: Which of the following is correct, or does it matter: ROUTE 1.123.456.0.* Crash 1:123/0.0@Fidonet ZIP -m -j -or- ROUTE 1.123.456.0.* Crash 1.123.0.0.* ZIP -m -j A: Again the first is correct. You want a 5D address as the third parameter, not an address mask like the first parameter. Q. I have a point off my system, what should my ROUTE statement look like for him? A: ROUTE 1.222.10.1.FIDONET POINTROUTE Same zip.exe -m -j ROUTE 1.222.10.2.FIDONET POINTROUTE Same ZIP.EXE -m -j then in your AREA.CONTROL put ECHO AdeptSoft 5 1:222/10.1@FIDONET 1:222/10.2@FIDONET CHECKSEENBYS Turns on SEEN-BY checking. Ex. CHECKSEENBYS PVTECHOASNET Tells GateKeeper to send private EchoMail as NetMail. Ex. PVTECHOASNET GRUNGEATTEMPTS <number> The maximum number of errors allowed in a packet before GateKeeper gives up on the packet as bad. The default is 48. For instance, GateKeeper will read a message from a packet. If for some reason it doesn't find a message where it expects it, it will go looking for one. This first retry would be a grunge attempt. If GateKeeper retries 48 times in a single packet, GateKeeper will mark the packet as bad, and go to the next packet. Ex. GRUNGEATTEMPTS 10 MESSAGES <path> The above tag tells GateKeeper where to place .MSG messages. Ex. NETPATH C:\Adept\MsgFiles HOLD <path> 10 The HOLD tag tells GateKeeper where to hold .TIC files. Ex. HOLD C:\ADEPT\MAILER\TICS FLAGSPATH GateKeeper or Adept create flags which tell whether not a node number is locked. For instance GateKeeper will lock a node number when it is creating a packet for that node. If Adept sees that a node is locked, it will not send mail to that system. That way the integrity of the mail is maintained. FLAGSPATH tells GateKeeper where AdeptXBBS is keeping it's flags for outgoing/incoming mail Ex. FLAGSPATH C:\ADEPT\MAILER\FLAGS PKTSORTER The PKTSORTER option tells GateKeeper the name and location of a packet sort program to run before the processing of a mail packet. Ex. PKTSORTER C:\UTILS\PKTSORT.EXE PASSWORD The above tag lets you set a .PKT password. Ex. PASSWORD 1:231/1320.0@Fidonet MYPASS IMPORTALLNETMAIL This keyword causes any NetMail going thru a system to be imported into the NetMail area. The NetMail will still go to the original recipient. If this keyword is not present, the current default behavior occurs which is that only netmail sent to the current system is imported into the netarea. Ex. IMPORTALLNETMAIL NEWAREASCREATE <address> Contains a list of FidoNet addresses which are allowed to create new echo areas. If this is remarked out, then ANY node can create new areas. Ex. NEWAREASCREATE 1:231/1320.0@Fidonet 1:18/232.0@Fidonet Sample GateKpr.Ctl File: LOGFILE C:\ADEPT\LOGFILES\GateKpr.Log ; INBOUND C:\ADEPT\MAILER\PASSWORD_INBOUND_MAIL INBOUND C:\ADEPT\MAILER\PUBLIC_INBOUND_MAIL INBOUND C:\ADEPT\MAILER\UNLISTED_INBOUND_MAIL ; OUTBOUND C:\ADEPT\MAILER\OUTBOUND_MAIL ; MSGDIR C:\ADEPT\MESSAGE_BASES ; ADDRESS 1:18/210.0@Fidonet ; NETAREA 99 ; PACKSIZE 65535 ; 11 AREAFILE AREA.CONTROL ; TONAME "AreaFix" AREACNTL TONAME "Area Control" AREACNTL ; ROUTE 1.142.*.*.* Crash Same ZIP.EXE -m -j ROUTE 1.320.*.*.* Crash Same ZIP.EXE -m -j ROUTE 3.800.887.0.* Hold Same ZIP.EXE -m -j ROUTE 1.*.*.*.* Crash Same ZIP.EXE -m -j ROUTE 2.*.*.*.* Crash Same ZIP.EXE -m -j ROUTE 3.*.*.*.* Crash Same ZIP.EXE -m -j ROUTE 4.*.*.*.* Crash Same ZIP.EXE -m -j ROUTE 5.*.*.*.* Crash Same ZIP.EXE -m -j ROUTE 6.*.*.*.* Crash Same ZIP.EXE -m -j ; 12 ___________________________ _ _ THE AREA.CONTROL FILE _ ___________________________ The AREA.CONTROL file is a echomail control file that Gatekeeper reads. It defines where echos are coming from and where they are going. Here are the keywords that are available to use in this file: DEFLOCK <default lock> Define Lock DEFLOCK and DEFKEY should come before any addresses in this file, if you wish to use them. ** Assign default lock to all areas not included in the PROTECT lines. Any locks present on PROTECT lines will take precedence. Ex. DEFLOCK Ab1 DEFKEY <default key> ** Assign default key to all addresses not included in the ADDRCONTROL lines. Any keys present on ADDRCONTROL lines will take precedence. Ex. DEFKEY Ab1 ECHO <ECHOID> <msg area #> <5D FTN addr> [<5D FTN addr>] [<5D FTN addr>] This keyword is used to list your fido echos, what message area # they are, and your up/downlinks. The first node in an echo list must have all 5 dimensions, the rest just need to contain the info that changes from the previous node. Ex. ECHO OS2 1 1:213/760.0@Fidonet 761 .4 245/76.0 2:234/12 That line is perfectly valid. The nodes in the list are: 1:213/760.0@Fidonet 1:213/761.0@Fidonet 1:213/761.4@Fidonet 1:245/76.0@Fidonet 2:234/12.0@Fidonet Also, echo control lines can be up to 1024 chars long, and if the sysop needs more room than that for node numbers, they can put a + as the last character of a line, and then the next line of text is considered a continuation of the previous line and more addresses can be put on it. If you want to setup an echo as passthru, use 0 as the message area number. Ex. ECHO ADEPT_BETA 1 1:213/760.0@fidonet ECHO AdeptSoft 2 1:213/760.0@fidonet ECHO OS2 3 1:213/760.0@fidonet ECHO C_ECHO 4 1:213/760.0@fidonet ECHO OS2BBS 5 1:213/760.0@fidonet 13 ECHO OS2PROG 6 1:213/760.0@fidonet ECHO OS2HW 0 1:213/760.0@fidonet ECHO OS2LAN 0 1:213/760.0@fidonet GROUP <groupid> <msg area#> <numdays> <5D FTN address | !topstar option> The above is the control statement outline for GROUP Mail. Ex. GROUP PROTECT <echo|group id> <seclevel[,lock]> ** Assign security level to an area for area control messages <echo|group id> Name of echo or group area to assign protection. <seclevel[,lock]> Security level assigned to this node address. may also contain a 'lock' similar to used with Areafix. To secure the area with a lock, separate it with a comma from the security level. for example: 5,FgH NOTE: You must include a security level before the comma, even if it is zero. Locking Mechanism: To put it simply, the nodes 'key' must contain all the characters contained in an areas 'lock'. No Lock?? Then, no key is necessary. Valid characters in a lock will be: A-Z, a-z, 0-9 Locks can be up to 15 characters in length Ex. PROTECT ADEPTBETA 6,GJk Ex. PROTECT OS2 5 ADDRCONTROL <5D FTN Address> <password> <seclevel[,key]> <flags> <password> Allows access to area control functions. A '.' can be used as a place holder. <seclevel[,key]> Security level assigned to this node address. This may also contain a 'key' similar to used with Areafix. To add a key, separate it with a comma from the security level. Ex. 5,DEFGH NOTE: To add a key, you must include a security level before the comma, even if it is zero. Locking Mechanism: To put it simply, the nodes 'key' must contain all the characters contained in an areas 'lock'. Valid characters in a key will be: A-Z, a-z, 0-9 14 Keys Can be up to 19 characters in length <flags> Flags to set for this node address. Current valid flags are: TYPE2 -- Build a type 2 packet for this node TYPE2+ -- Build a type 2+ packet for this node TYPE2QM -- Build a type 2 packet w/QMail revisions for this node TYPE2+QM -- Build a type 2+ packet w/QMail revisions for this node (default) TYPE2DOT2 -- Built a type 2.2 packet for this node @PATH -- Means that this address requires echomail to contain PATH lines. This should be turned on only for nodes which require PATH lines. If a node doesn't need PATH lines, then don't use this flag. NOTE: A security level must be on the line to set the flags There has to be some order when creating the ADDRCONTROL line. For instance. It is valid to have only two entries on this line, address, and password. If you want to set a security level, you must 3 entries on the line. If you want to set the flags, you must have 4 entries on the line. Ex. ; Valid ADDRCONTROL 1:213/760.0@FIDONET JUNK ADDRCONTROL 1:213/761.0@FIDONET FRITZ 80 ADDRCONTROL 1:213/762.0@FIDONET HANDS 99 @PATH ADDRCONTROL 1:213/763.0@FIDONET . 100 TYPE2 ADDRCONTROL 1:213/763.0@FIDONET PASS 100 TYPE2+,@PATH ; Invalid lines ; Next line. GateKeeper thinks password is 75 ADDRCONTROL 1:213/760.0@FIDONET 75 ; Next line GateKeeper thinks password is TYPE2+ ADDRCONTROL 1:213/761.0@FIDONET TYPE2+ ; Next line GateKeeper thinks password is 99 ADDRCONTROL 1:213/762.0@FIDONET 99 TYPE2 15 ___________________________ _ _ THE FILE.CONTROL FILE _ ___________________________ .TIC File Echo Configuration For GateKeeper TIC-Style file areas are supported by GateKeeper. We call it FILE.CONTROL. The TZ environment variable should be set the same as if you were using TICK. i.e.: SET TZ=PST8PDT All file control information is normally stored in a file called FILE.CONTROL But you can specify any name you wish. To specify a name, use the FILEAREA keyword in GateKpr.Ctl: FILEAREA filename Ex. FILEAREA FILE.CONTROL NOTE: the FILEAREA keyword in GateKpr.Ctl is different than the FILEAREA keyword when read from the FILE.CONTROL file. Other file control keywords are (found in GateKpr.Ctl): NOTICCRC Don't check or generate CRC-32's for the files in this area. This will only happen if the TIC file received also had no CRC-32 in it. If the TIC had a CRC-32 in it, it is passed on to the downstream nodes. This keyword is a global keyword. It causes ALL file control areas to bypass generating and checking TIC CRC-32's. Ex. NOTICCRC DELETEFILEDUPES If you have TIC CRC-32 checking enabled and a file has the same name, area and CRC as a previous file, it will be deleted. If this option is off, then the TIC file is renamed and the duplicate is logged. You can then decide what needs to be done with the file. By default deleting is off. Ex. DELETEFILEDUPES FILECOLLISION [action] A file collision happens when you try to add a file to an AdeptXBBS file area which has the same filename as a file already in that area. The FILECOLLISION keyword helps you tell Gatekeeper what to do in that event. The following are the current available actions: OVERWRITE This deletes the entry for the old file and puts the new file in its place. Only the entry in the file system is deleted. The actual file may not be deleted or overwritten if it is not in one of the directories specified for that file area. OVERWRITE is the default. RENAMEOLD This renames the older file to a unique name and adds the new file 16 to the file area. RENAMENEW This renames the new file to a unique name and adds it to the file area. Ex. FILECOLLISION RENAMEOLD HOLD [path] This is the file control hold path. Files and TICs are placed there while they are waiting to be sent. Dupe files are also stored here. Ex. HOLD C:\ADEPT\MAILER\HOLD FILEAREA AreaNum AreaName AreaNum = Adept File Area Number 0 = no corresponding AdeptXBBS file area, in other words a passthru file area. When a corresponding AdeptXBBS file area is found, the file is moved into the upload directory for that file area and the file and its description are added to the file system in that area. AreaName = TIC file area name Corresponds to the file area found in the .TIC file. Ex. FILEAREA 2 Games FLAGS flag1 [flag2] [flag3] Flags control how this area is acted upon. Flags do not need to be included for each area. If you have a flags line, it should follow the FILEAREA line. Valid flags are: DLDIR Instead of moving the file to that areas upload path, move it to that areas download path. NOTICCRC Don't check or generate CRC-32's for the files in this area. This will only happen if the TIC file received also had no CRC-32 in it. If the TIC had a CRC-32 in it, it is passed on to the downstream nodes. CHECKDUPES Checks for TIC duplicates. This involves saving the file name, the area it is associated with and the CRC-32 of the file. You should use this flag in each area where you wish to have checking for TIC duplicates. Gatekeeper also employs checking for AdeptXBBS style duplicates. These duplicates occur when a file goes into an AdeptXBBS file area which already has a file of the same name. See the FILECOLLISION keyword above to specify the action Gatekeeper should take on AdeptXBBS duplicates. NOTE: AdeptXBBS duplicate checking is employed at all times! AdeptXBBS allows for duplicate filenames in the file system, but they cannot be in the same file area. 17 More flags will be supported in the future, along with more keywords for each file area. Following the FILEAREA and FLAGS keywords must be one or more nodes which may deal with this area. The first may be the node from which you received the file, the following nodes would be the nodes you are sending the file to. But, the order is not important. ADDRESS <Password> <Flags> A Valid address, can be 3D, 4D or 5D address. TIC appears to work with 3D addresses. Gate Keeper will do 5D. Password Password used when dealing with this node. When receiving a file, this password must match the password in the .TIC file or the .TIC file is considered invalid. When sending to a node, password is put into the .TIC file. A password is required at this time. Flags Contains one or more flags. Valid flags are: S - Secure password mode. The password is sent in a numerical form, not as the password itself. Any nodes using the secure password option should have the S flag set for each node it is swapping secure passwords with. This will only work with systems running GateKeeper! R - Node is Read-Only. In other words, we should only receive files from this node. We will not send any files to this node. W - Node is Write-Only. We should only send files to this node, we will not receive any files from this node. If we do receive a file or files, we will ignore it. H - Hold Flag. C - Crash Flag. D - Direct Flag. N - Normal Flag. 5 - 5D address flag. Puts 5D addresses into .TIC file. Not recommended unless you are sending to a system which won't puke when it finds a 5D address in a .TIC file. (i.e. Another AdeptXBBS system) - NOT YET IMPLEMENTED - Flags can be combined: WH = Write only, put files on hold. WC5 = Write only, crash files to node, put 5D addresses in .TIC file. Format of FILE.CONTROL: FILEAREA AreaNum AreaName Address Password Flags ; ; this is a remark ; FILEAREA AreaNum AreaName FLAGS DLDIR Address Password Flags Address Password Flags 18 ; FILEAREA AreaNum AreaName Address Password Flags Address Password Flags ; ; ; etc. Example FILE.CONTROL File: FILEAREA 23 Games FLAGS DLDIR 1:100/600 Hello WH 1:100/800 Wow WH 1:120/10 Floopy WH FILEAREA 1 AdNetUplink FLAGS DLDIR 1:100/600 Hello RH 1:100/800 Wow RH 1:120/0 Floopy RH 19 ______________________________________ _ _ OUTBOUND MAIL NAMING CONVENTIONS _ ______________________________________ AdeptXBBS uses long file names for it's mail packets. The following is the basic outline for all Adept Mail Packets. TYPE.ZONE.NET.NODE.POINT.NETWORK TYPE Can be any of the following. A = Archived Mail Packet R = File Request H = Hold Mail C = Crash Mail D = Direct Mail N = Normal Mail P = Unarchived Packet M = Manual C, N, D, H, M are modifiers. And can also contain the name of a file to be sent using that particular flavor. For example you can have a archived mail packet for me. 1:142/210.0@Fidonet. A.1.142.210.0.Fidonet Now say you want to send it crash mail, you can then create a 0 byte file as 'C.1.142.210.0.Fidonet'. To send a file attach to me at 1:142/210.0@Fidonet. You would create a file called 'C.1.142.210.0.Fidonet' And on the first line of the file place the name of the file to crash mail to me. C:\ADEPT\MYFILE.TXT If you append a ' before the name it will delete the file after it had been sent. 20 ___________________________ _ _ AREAFIX TYPE COMMANDS _ ___________________________ Gatekeeper accepts lines in an Areafix style message that begin with '+' Gatekeeper accepts lines in an AreaFix style message that begin with '%' the two key words recognized are 'query' and 'list' all other words are ignored at this time. In the \Adept\gatekpr.ctl add the following line: TONAME "AreaFix" AREACNTL "Areafix" can be anything, but Areacontrol is usually called AreaFix or AreaMgr. Also define your downlink's Areafix password's in the AREA.CONTROL file. That is outlined in more detail in the section on AREA.CONTROL. Here is an example of a message that your downlink might write to 'AreaFix' to tell AreaFix what it has to do for him/her. Ex. Msg : 13 of 23 Uns Pvt Loc K/s From : Joe Smoe 1:282/9999 Wed 31 Dec 93 23:59 To : AreaFix 1:282/3029 <--Address of your BBS Subj : PASSWORD <- Your AreaFix password --------------------------------------------------------------------- +RA_UTIL <- Add (link) area -SYSOPS.024 <- Remove (unlink) area %QUERY <- Ask for your active areas %LIST <- List available areas 21 _____________________________________ _ _ TEXT FILES USED WITH THE MAILER _ _____________________________________ OK Files: An `OK' file is a file that tells your mailer which files are available for people to FREQ (File Request) from you. Create a PUBLIC.OK file and place it in your \Adept\Mailer directory. OK files follow the 'Binkley' style OK file format where MAGIC names have a `@' in front of them. Otherwise, the file path is listed so that any file in that path can be FREQed. In the example below, a person can FREQ SIO142.ZIP by using the magic name SIO @ADEPTXBBS C:\Files\Adept\Adept_90.Zip @SIO C:\Files\Comm\Sio142.Zip @NODELIST D:\fido\fidofile\Nodelist.A?? @NODEDIFF D:\fido\fidofile\nodediff.A?? D:\Files\netupld\*.* D:\Files\upload\*.* D:\Files\fidofile\*.* D:\Files\games\*.* D:\Files\utilities\*.* Other Text Files Used With The Mailer: These are looked for when your system gets a bad file request (FREQ). Create these files and place them in your \Adept directory. SYSTREQ.TXT System error (as in BBS program) Could have been, say, unable to allocate memory etc. SYSPREQ.TXT OK File list not found. Sysop hasn't created them or maybe in the wrong dir. BADPREQ.TXT Passwords don't match. Password on file request didn't match. BADFREQ.TXT File request not found on system. Pretty self explanatory :) GATEKPR.SF$ A file which is used to recover from either a GateKeeper crash, or an OS/2 system crash. It basically helps GateKeeper remember where it was in a packet, so when it resumes, it starts from where it left off. It is a harmless file which may be found in the Adept directory. Configurable Mail Directories: There are three distinct inbound directories that can be used. They should, ideally, all be on the same drive (the default) The directories are for, in order: .\Mailer\Password_Inbound_Mail -- Passworded connections 22 .\Mailer\Public_Inbound_Mail -- Unpassworded but listed connections .\Mailer\Unlisted_Inbound_Mail -- Unlisted connections There are corresponding OkFile listings as well. .\Mailer\Password_File_List .\Mailer\Public_File_List .\Mailer\Unlisted_File_List The directory to be used is decided after the YooHoo packet is exchanged or after the introductory packet is received in an FTS-0001 session. When Adept starts a session with the ext(ernal)mail processor because mail was received, it passes the inbound directory currently in use (which is usually where the mail will be :-). If you press M for Mail Processing at the "waiting" screen, the first outbound area will always be passed. You can change these directories from Adepts setup dialog boxes. Bad Mail Packet File Descriptions: Insecure.$$$ ONLY created when you receive messages in a known message area from a node that is not defined in the AREA.CONTROL file. Unknown.$$$ Created if the area does not exist. Mail.Cmd A Sample mail processing command file: The Mail.Cmd file is a sample batch file for handling incoming mail processing. GateKpr.Exe GateKpr.Ctl A LP 23 ____________________ _ _ REPORTING BUGS _ ____________________ If you are reporting a bug, please, try to be as specific as possible. I.E. - "The mailer is broken" doesn't give us any idea as to what is broken in the mailer. Also please to not get discouraged if you are having problems. Many times it's something simple that can be fixed with a quick phone call. So please leave a phone number you may be reached at. Use the form below to report bugs that you find in the software. This is the ONLY accepted way to report a bug. === AdeptXBBS Bug Report Form ========================================== = = = This form has been created to allow a more organized approach to bug = = reporting. Please fill it out and send it to julies@adeptsoft.com, = = netmail it to 1:231/1320.0@FidoNet, or FTP to adeptsoft.com. = = = = The current bug list can be found on the support bbs FTP site in the = = BUG_REPORTS directory or by FREQing it from 1:231/1320.0@FidoNet = = using the magic name of BUGLIST = = = = Only report one bug/problem per form please. This will allow better = = tracking. = = = = *Do Not Use This Form To Ask For New Features* = ======================================================================== ---8<----cut here----8<--- Date : ________ Sysop Name : _____________________________________ E-Mail Address: _____________________________________ Fido Address : _____________________________________ BBS Number : _____________________________________ Voice Number : _____________________________________ What version of AdeptXBBS are you running? : ___________ What version of Gatekpr.Exe are you running? : ___________ Put an 'X' for which area this bug report is in reference to: _ File Area _ NNTP _ Telnet _ IRC _ Mailer (FidoNet) _ Menu System (.menu files and commands) _ Message Area _ Offline Mail 24 _ Meta Variables _ REXX _ Documentation _ Interface _ Gatekpr (* MUST include your GateKpr.Ctl, AREA.CONTROL, FILE.CONTROL, Message_Areas and the packet that is causing problems *) Has this problem occurred more than once? ____________________________ Can you reproduce it? ________________________________________________ What problem are you having? (Be as detailed and specific as possible, if you can repeat the problem please try to explain as best as possible how to exactly make it occur): ______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________ ______________________________________________________________________ Is there a good time we can call you if we need some more verbal information relating to this problem report? _________________________ ---8<----cut here----8<--- *** If error is with GateKeeper, did you include your control files and any packets which cause Gatekeeper to run erratically? (Control files include GateKpr.Ctl, AREA.CONTROL, FILE.CONTROL, Message_Areas) Inclusion of these files will greatly aid in the resolution of your problem. "Gather enough information, and the solution will be obvious"